Integrating Datalog with OWL: Exploring the AL-log Approach

We present OWL-log, which is an implementation of the ALlog hybrid knowledge representation system where the Description Logics component is extended to the Web Ontology Language OWL DL. We implemented an OWL-log reasoner coupled to the OWL reasoner Pellet and explored different query-answering strategies. We conducted an experimental study using a modified version of the LUBM benchmark in order to evaluate and compare the efficiency of the strategies. Also, to validate OWL-log’s usefulness we developed a prototype based on the Web ontology browsing and editing tool Swoop. 1 The OWL-log System OWL-log is an implementation of the hybrid knowledge representation system AL-log [5] that combines Description Logics (DL) and Datalog components. OWL-log restricts the Datalog atoms to be unary or binary, and the DL component is extended to the Web Ontology Language OWL DL. A constrained OWL-log clause is an axiom in which only OWL DL Class and Datatype predicates are allowed in the antecedent of the rules as constraints. Datalog predicates in an OWL-log clause are limited to being OWL DL classes and properties that are not being used in any of the axioms that belong to the DL component (we define these concepts as Atomic). Our approach is to evolve the Web Ontology Language OWL DL toward the Semantic Web Rule Language (SWRL) while retaining practical decidability. An important application for a system like OWL-log can be Web policies. For instance, we may write a policy rule to specify permissions on a set of services: hasPermission(P, S) :relatedTo(S, K), participates(O, K), memberOf(P, O), & K:JointProject, S:Service, P :Person, O:Organization. Note that to comply with the OWL-log rule definition, the predicates relatedTo, participates and memberOf , will be Atomic concepts (Datalog predicates). On the other hand JointProject is a defined class in the DL component: JointProject ≡ Project u ≥ 2 organizedBy. Our work differs from other systems that rely on translating the DL and rules components to a common logical language [2, 3] and using rule engines for inferencing. OWL-log is a combined approach where both components are kept separately but with an interface handled through the DL atoms in the rules component, and its decision procedure is based on a combination of DL and Datalog reasoners. 2 Implementation and Evaluation We have developed two different query-answering strategies: Dynamic and Precompilation. In Dynamic, the method used for answering a query is based on the notions of constrained SLD-derivation and constrained SLD-refutation [5]. The key idea of Precompilation is to pre-process all of the DL atoms that appear in the Datalog rules, and include them as facts in the Datalog subsystem; once the pre-processing is done, queries can be answered by the Datalog component using any of the known techniques for Datalog query evaluation. According to [5], constrained SLD-resolution is complete and correct. Thus, Dynamic is a complete and correct procedure. Precompilation is a complete query-answering procedure only for DL-safe rules, that is rules in which each variable is bound to individuals that are explicit in the ABox [4]. We conducted an experimental study to compare the performance of the Dynamic and Precompilation query-answering strategies. Our test case of choice was a modified version of the LUBM benchmark [1] with one university and increasing ABox sizes. The performance evaluation results show that Precompilation performs better than Dynamic for queries where there is a large number of results (valid bindings) because in Dynamic, the query-answering time depends on the number of constrained empty clauses. On the other hand, Precompilation does worse than Dynamic when a large number of intermediate predicates are inferred in the Datalog component. Future work includes improving this time with query optimization techniques that include cost-based join-ordering strategies and Magic-Sets rewriting.